home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / ip / nfs / amd / amd-5.2 / doc / maps.tex < prev    next >
Encoding:
Text File  |  1990-06-23  |  25.6 KB  |  594 lines
  1. % $Id: maps.tex,v 5.2 90/06/23 22:21:51 jsp Rel $
  2. %
  3. % Copyright (c) 1989 Jan-Simon Pendry
  4. % Copyright (c) 1989 Imperial College of Science, Technology & Medicine
  5. % Copyright (c) 1989 The Regents of the University of California.
  6. % All rights reserved.
  7. %
  8. % This code is derived from software contributed to Berkeley by
  9. % Jan-Simon Pendry at Imperial College, London.
  10. %
  11. % Redistribution and use in source and binary forms are permitted provided
  12. % that: (1) source distributions retain this entire copyright notice and
  13. % comment, and (2) distributions including binaries display the following
  14. % acknowledgement:  ``This product includes software developed by the
  15. % University of California, Berkeley and its contributors'' in the
  16. % documentation or other materials provided with the distribution and in
  17. % all advertising materials mentioning features or use of this software.
  18. % Neither the name of the University nor the names of its contributors may
  19. % be used to endorse or promote products derived from this software without
  20. % specific prior written permission.
  21. % THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
  22. % WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
  23. % MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  24. %
  25. %    %W% (Berkeley) %G%
  26.  
  27.  
  28. \Chapter{Mount-maps}
  29.  
  30. \Amd\ has no built-in knowledge of machines or filesystems.
  31. External {\em mount-maps} are used to provide the required information.
  32. Specifically, \amd\ needs to know when and under what conditions it should
  33. mount filesystems.
  34.  
  35. The map entry corresponding to the requested name contains
  36. a list of possible locations from which to resolve the request.
  37. Each location specifies  filesystem type, information required by that
  38. filesystem (for example the block special device in the case of \UFS), and
  39. some information describing where to mount the filesystem (\see \Ref{mount location}).
  40. A location may also contain {\em selectors} (\see \Ref{selectors}).
  41.  
  42. \Section{Map Types}
  43.  
  44. A mount-map can be implemented as a regular file, an ndbm database
  45. a YP map \cite{sun:yp} or via
  46. the {\em Hesiod} \cite{mit:hesiod} name
  47. server.
  48. In addition, the password ``file'' can be used as a source of
  49. map information.
  50. %\footnote{In future, gdbm databases will also be supported.}
  51. A mount-map name is a sequence of characters.
  52. When an automount point is created a handle on the mount-map
  53. is obtained.  If the the map name begins with the sequence
  54. ``{\tt hesiod.}''\ then the {\em Hesiod} name server will be used.
  55. If the map name is the string ``{\tt /etc/passwd}'' then the password
  56. ``file'' will be used.
  57. Otherwise the map name is referenced as a file,
  58. then as an ndbm database by that name and then as a YP map.
  59. As soon as a valid reference is found the map type is noted
  60. for future use but any resources held are released, for example
  61. any open file descriptors are closed.
  62. The available map types are a configurable component of \amd\ and
  63. can be displayed by running the command {\tt amd~-v}.
  64.  
  65. By default, \amd\ does not cache any data retrieved from a mount map.
  66. This is a policy decision based on the observation that most workstations
  67. have more available CPU time than spare memory.
  68. However, on a multi-user service or larger workstation the faster
  69. response provided by a cache can be preferable.  The \opt{cache}
  70. option can be specified on automount points to alter the
  71. caching behaviour (\see \Ref{auto-fs}).
  72. Specifying {\tt cache:=mapdefault} selects a suitable default
  73. cache mode depending on the map type.  The individual defaults
  74. are described below.
  75.  
  76. \Subsection{File maps}
  77. When \amd\ searches a file for a map entry it does a simple scan of the file
  78. and supports both comments and continuation lines.
  79.  
  80. Continuation lines are indicated by a backslash character (``{\verb+\+}'') as
  81. the last character of a line in the file.  The backslash, newline character
  82. {\em and any leading white space on the following line} are discarded.  A maximum
  83. line length of 2047 characters is enforced after continuation lines are read
  84. but before comments are stripped.  Each line must end with
  85. a newline character; that is newlines are terminators, not separators.
  86. The following examples illustrate this:
  87. \begin{verbatim}
  88. key     valA   valB;   \
  89.           valC
  90. \end{verbatim}
  91. specifies {\em three} locations, and is identical to
  92. \begin{verbatim}
  93. key     valA   valB;   valC
  94. \end{verbatim}
  95. However,
  96. \begin{verbatim}
  97. key     valA   valB;\
  98.           valC
  99. \end{verbatim}
  100. specifies only {\em two} locations, and is identical to
  101. \begin{verbatim}
  102. key     valA   valB;valC
  103. \end{verbatim}
  104.  
  105. After a complete line has been read from the file, including continuations,
  106. \amd\ determines whether there is a comment on the line.
  107. A comment begins with a hash (``{\tt \#}'') character and continues to the
  108. end of the line.
  109. There is no way to escape or change the comment lead-in character.
  110.  
  111. Note that continuation lines and comment support {\em only} apply to
  112. file maps and ndbm maps built with the {\tt mk-amd-map} program.
  113.  
  114. When caching is enabled, file maps have a default cache mode of {\tt all} (\see \Ref{afs:cache}).
  115.  
  116. \Subsection{ndbm maps}\label{ndbm-maps}
  117. An ndbm map may be used as a fast access form of a file map.
  118. A program, {\tt mk-amd-map}, converts a normal map file into
  119. an ndbm database.  This program supports the same continuation and
  120. comment conventions that are provided for file maps.
  121. Note that ndbm format files {\em may not} be
  122. sharable across machine architectures.
  123. The notion of speed generally only applies to large maps;
  124. a small map, less than a single disk block, is almost certainly
  125. better implemented as a file map.
  126.  
  127. ndbm maps do not support cache mode {\tt all} and, when
  128. caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
  129.  
  130. \Subsection{NIS maps}
  131. When using NIS (formerly YP), an \amd\ map is implemented directly by the
  132. underlying NIS map.
  133. Comments and continuation lines are {\em not} supported
  134. in the automounter and must be stripped when constructing the NIS server's database.
  135.  
  136. NIS maps do not support cache mode {\tt all} and,
  137. when caching is enabled,
  138. have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
  139.  
  140. \Subsection{Hesiod}
  141. When the map name begins with the string ``{\tt hesiod.}'' lookups
  142. are made using the {\em Hesiod} name server.  The string following
  143. the dot is used as a name qualifier and is prepended with
  144. the key being located.  The entire string is then resolved in the
  145. {\t automount} context.  For example, if the map name is {\tt hesiod.homes}
  146. and the key is {\tt jsp} then {\em Hesiod} is asked to resolve
  147. {\tt jsp.homes.automount}.
  148.  
  149. Hesiod maps do not support cache mode {\tt all} and, when
  150. caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
  151.  
  152. \Subsection{Password}\label{map:passwd}
  153. The password map support is unlike the four previous map types.
  154. When the map name is the string {\tt /etc/passwd} 
  155. \amd\ can lookup a user name in the password file and re-arrange
  156. the home directory field to produce a usable map entry.
  157.  
  158. \Amd\ assumes the home directory has the format
  159. {\tt /}{\em anydir}{\tt /}{\em dom$_1$}{\tt /../}{\em dom$_n$}{\tt /}{\em login}.
  160. It breaks this string into a map entry where
  161. \Var{rfs} has the value ``{\tt /}{\em anydir}{\tt /}{\em dom$_n$}'',
  162. \Var{rhost} has the value ``{\em dom$_n$}{\tt .}{\em ...}{\tt .}{\em dom$_1$}'',
  163. and \Var{sublink} has the value ``{\em login}''.
  164.  
  165. Thus if the password file entry was
  166. \begin{quote}
  167. \tt /home/achilles/jsp
  168. \end{quote}
  169. the map
  170. entry used by \amd\ would be
  171. \begin{quote}
  172. \tt rfs:=/home/achilles;rhost:=achilles;sublink:=jsp
  173. \end{quote}
  174. Similarly, if the password file entry was
  175. \begin{quote}
  176. \tt /home/cc/sugar/mjh
  177. \end{quote}
  178. the map entry used by \amd\ would be 
  179. \begin{quote}
  180. \tt rfs:=/home/sugar;rhost:=sugar.cc;sublink:=jsp
  181. \end{quote}
  182.  
  183. %\Subsection{Gdbm}
  184.  
  185. \Section{Key Lookup}
  186.  
  187. The key is located in the map whose type was determined when the
  188. automount point was first created.
  189. In general the key is a pathname component.
  190. In some circumstances this may be modified by variable expansion
  191. (\see \Ref{var-expansion})
  192. and prefixing.
  193. If the automount point has a prefix, specified by the \opt{pref} option, then
  194. that is prepended to the search key before the map is searched.
  195.  
  196. If the key cannot be found then a {\em wildcard} match is attempted.
  197. Currently this simply attempts to locate a special key ``{\tt *}''.
  198. If the wildcard is not found then an error code is propagated back to the
  199. kernel, otherwise \amd\ proceeds as if an exact match had been found.
  200. The value field is then used to resolve the mount request (\see \Ref{filesystems}).
  201.  
  202.  
  203. \Section{Location Format}\label{opts:values}
  204.  
  205. The value field from the lookup provides the information required to mount a filesystem.
  206. The information is parsed according to the syntax shown in figure \ref{figure:so-grammar}.
  207. \begin{figure}[htb]
  208. \begin{tabbing}
  209. Indent \= Long Gram Rule \= \kill
  210.        \> {\em location-list}:\\
  211.        \>              \> {\em location-selection}\\
  212.        \>              \> {\em location-list}\ \verb*+ +\ {\tt ||}\ \verb*+ +\ {\em location-selection}\\
  213.        \> {\em location-selection}:\\
  214.        \>              \> {\em location}\\
  215.        \>              \> {\em location-selection}\ \verb*+ +\ {\em location}\\
  216.        \> {\em location}:\\
  217.        \>              \> {\em location-info}\\
  218.        \>              \> {\tt -}{\em location-info}\\
  219.        \>              \> {\tt -}\\
  220.        \> {\em location-info}:\\
  221.        \>              \> {\em sel-or-opt}\\
  222.        \>              \> {\em location-info}{\tt ;}{\em sel-or-opt}\\
  223.        \>              \> {\tt ;}\\
  224.        \> {\em sel-or-opt}:\\
  225.        \>              \> {\em selection}\\
  226.        \>              \> {\em opt-ass}\\
  227.        \> {\em selection}:\\
  228.        \>              \> {\rm selector}{\tt ==}{\em value}\\
  229.        \>              \> {\rm selector}{\tt !=}{\em value}\\
  230.        \> {\em opt-ass}:\\
  231.        \>              \> {\rm option}{\tt :=}{\em value}\\
  232. \end{tabbing}
  233. \caption{\label{figure:so-grammar}Location syntax}
  234. \end{figure}
  235. Note that unquoted whitespace is not allowed in a location description.
  236. White space is only allowed, and is mandatory, where shown with the symbol \verb*+ +.
  237.  
  238. A {\em location-selection} is a list of possible volumes with which to
  239. satisfy the request.  {\em location-selection}s are separated by the {\tt ||}
  240. operator.  The effect of this operator is to prevent use of location-selections
  241. to its right if any of the location-selections on its left were selected
  242. (see \Ref{selectors}).
  243.  
  244. The location-selection, and singleton {\em location-list},
  245. {\tt type:=ufs;dev:=/dev/xd1g} would inform \amd\ to mount a
  246. \UFS\ filesystem from the block special device {\tt /dev/xd1g}.
  247.  
  248. The {\em sel-or-opt} component is either the name of an option required by a
  249. specific filesystem, or it is the name of a built-in, predefined selector such
  250. as the architecture type.
  251. The value may be quoted with double quotes ``{\tt "}'',
  252. for example {\tt type:="ufs";dev:="/dev/xd1g"}.  These quotes are
  253. stripped when the value is parsed and there is no way to get a double quote
  254. into a value field.  Double quotes are used to get white space into a value field,
  255. which is needed for the program filesystem (\see \Ref{pfs}).
  256.  
  257. \label{defaults}A location beginning with a dash ``{\tt -}'' is used
  258. to specify default values for subsequent locations.
  259. Any previously specified defaults in the location-list are discarded.  The
  260. default string can be empty in which case no defaults apply.
  261. The location {\tt -fs:=/mnt;opts:=ro} would set the local mount point
  262. to {\tt /mnt} and cause mounts to be read-only by default.
  263. Defaults specified this way are appended to, and so
  264. override, any global map defaults given
  265. with {\tt /defaults}\label{/defaults}).
  266. A {\tt /defaults} value {\em gdef} and a location list
  267. \begin{quote}
  268. ${\tt -}{\em def}_a\ $\verb*+ +$\ {\em loc}_{a_1}\ $\verb*+ +$\ {\em loc}_{a_2}\ $\verb*+ +$\ {\tt -}{\em def}_b\ $\verb*+ +$\ {\em loc}_{b_1}\ \ldots$
  269. \end{quote}
  270. is equivalent to
  271. \begin{quote}
  272. ${\tt -}{\em gdef}{\tt ;}{\em def}_a\ $\verb*+ +$\ {\em loc}_{a_1}\ $\verb*+ +$\ {\em loc}_{a_2}\ $\verb*+ +$\ {\tt -}{\em gdef}{\tt ;}{\em def}_b\ $\verb*+ +$\ {\em loc}_{b_1}\ \ldots$
  273. \end{quote}
  274.  
  275. \Subsection{Variable expansion}\label{var-expansion}
  276.  
  277. To allow generic location specifications \amd\ does variable expansion
  278. on each location and also on some of the option strings.
  279. Any option or selector appearing in the form \Var{{\em var}}
  280. is replaced by the current value of that option or selector.
  281. For example, if the value of \Var{key} was {\tt bin}, \Var{autodir} was {\tt /a}
  282. and \Var{fs} was \Var{autodir}{\tt /local/}\Var{key} then after
  283. expansion \Var{fs} would have the value {\tt /a/local/bin}.
  284. Any environment variable can be accessed in a similar way.
  285.  
  286. Two pathname operators are available when expanding a variable.
  287. If the variable name begins with ``{\tt /}'' then only the
  288. last component of then pathname is substituted.  For example,
  289. if \Var{path} was {\tt /foo/bar} then \Var{/path} would be
  290. expanded to {\tt bar}.
  291. Similarly, if the variable name ends with ``{\tt /}'' then all but
  292. the last component of the pathname is substituted.
  293. In the previous example, \Var{path/} would be expanded to {\tt /foo}.
  294.  
  295. Variable expansion is a two phase process.  Before a location is parsed, all
  296. references to selectors, \eg\ \Var{path}, are expanded.  The location is then
  297. parsed, selections are evaluated and option assignments recorded.  If there
  298. were no selections or they all succeeded the location is used and the values of
  299. the following options are expanded in the order given:
  300. \opt{sublink}, \opt{rfs}, \opt{fs}, \opt{opts}, \opt{mount} and \opt{unmount}.
  301. Note that expansion of option values is done after {\em all} assignments have
  302. been completed and not in a purely left to right order as is done by the shell.
  303. This generally has the desired effect but care must be taken if one of the
  304. options references another, in which case the ordering can become significant.
  305.  
  306. There are two special cases concerning variable expansion.  Firstly, before a map
  307. is consulted, any selectors in the name received from the kernel are expanded.
  308. For example, if the request from the kernel was for \Var{arch}{\tt .bin} and the
  309. machine architecture was {\tt vax}, the value given to \Var{key} would be {\tt vax.bin}.
  310. Secondly, the value of \Var{rhost} is expanded and normalized before the other options
  311. are expanded.  The normalization process strips any local sub-domain components.
  312. For example, if \Var{domain} was {\tt Berkeley.EDU} and \Var{rhost} was initially
  313. {\tt snow.Berkeley.EDU}, after the normalization it would simply be {\tt snow}.
  314.  
  315. \Subsection{Selectors}\label{selectors}
  316.  
  317. Selectors are used to control the use of a location.
  318. It is possible to share a mount map between many machines in
  319. such a way that filesystem location, architecture and operating
  320. system differences are hidden from the users.
  321. A selector of the form {\tt arch==sun3;os==sos4} would only apply
  322. on Sun-3s running SunOS 4.$x$.
  323.  
  324. Selectors are evaluated left to right.  If a selector fails then that
  325. location is ignored.  Thus the selectors form a conjunction and the
  326. locations form a disjunction.
  327. If all the locations are ignored or otherwise fail then \amd\ uses
  328. the {\em error} filesystem (\see \Ref{error-fs}).  This is equivalent
  329. to having a location {\tt type:=error} at the end of each mount-map
  330. entry.
  331.  
  332. The selectors currently implemented are:
  333.  
  334. \begin{list}{}%
  335. {\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
  336. \item[\tt arch\hfill]
  337. the machine architecture which was automatically determined at compile time.
  338. The architecture type can be displayed by running the command {\tt amd~-v}.
  339. The currently supported architectures are listed in table \ref{table:arch}.
  340. \begin{table}[htb]
  341. \centering
  342. \begin{tabular}{ll}
  343. Name        & Architecture \\ \hline
  344. \tt alliant    & Alliant FX/4 \\
  345. \tt arm        & Acorn ARM \\
  346. \tt encore      & Encore (reserved) \\
  347. \tt fps500    & FPS Model 500 \\
  348. \tt hp9000    & HP 9000/300 family \\
  349. \tt hp9k8       & HP 9000/800 family (reserved) \\
  350. \tt ibm032    & IBM RT \\
  351. \tt ibm6000    & IBM RISC System/6000 \\
  352. \tt macII    & Apple Mac II \\
  353. \tt mips    & MIPS R2000 \\
  354. \tt multimax    & Encore Multimax \\
  355. \tt orion105    & HLH Orion 1/05 \\
  356. \tt powernode    & Gould Powernode family \\
  357. \tt sun3    & Sun-3 family \\
  358. \tt sun4    & Sun-4 family \\
  359. \tt tahoe    & Tahoe family \\
  360. \tt vax        & DEC \sc Vax \\
  361. \end{tabular}
  362. \caption{\label{table:arch}Architectures supported by \amd}
  363. \end{table}
  364.  
  365. \item[\tt autodir\hfill]
  366. the default directory under which to mount filesystems.
  367. This may be changed by the ``-a'' command line option.
  368. See the \opt{fs} option.
  369.  
  370. \item[\tt byte\hfill]\label{byte-selector}
  371. the machine's byte ordering.  This is either {\tt little}, indicating
  372. little-endian, or {\tt big}, indicating big-endian.
  373. One possible use is to share {\tt rwho} databases (see \Ref{example:rwho}).
  374. Another is to share ndbm databases,
  375. however this use can be considered a courageous juggling act.
  376.  
  377. \item[\tt cluster\hfill]
  378. is provided as a hook for the name of the local cluster.  This can
  379. be used to decide which servers to use for copies of replicated filesystems.
  380. \Var{cluster} defaults to the value of \Var{domain} unless a different
  381. value is set with the ``-C'' command line option.
  382.  
  383. \item[\tt domain\hfill]
  384. the local domain name as specified by the ``-d'' command line option.
  385. See {\tt host}.
  386.  
  387. \item[\tt host\hfill]
  388. the local hostname as determined by {\bf gethostname}(2).
  389. If no domain name was specified on the command line
  390. and the hostname contains a period ``{\tt .}'' then the string
  391. before the period is used as the host name, and the string
  392. after the period is assigned to \Var{domain}.
  393. For example, if the hostname is {\tt styx.doc.ic.ac.uk} the {\tt host}
  394. would be {\tt styx} and {\tt domain} would be {\tt doc.ic.ac.uk}.
  395. {\tt hostd} would be {\tt styx.doc.ic.ac.uk}.
  396.  
  397. \item[\tt hostd\hfill]
  398. is \Var{host} and \Var{domain} concatenated with a ``{\tt .}'' inserted between them
  399. if required.
  400. If \Var{domain} is an empty string then \Var{host} and \Var{hostd} will
  401. be identical.
  402.  
  403. \item[\tt karch\hfill]
  404. is provided as a hook for the kernel architecture.  This is used
  405. on SunOS 4, for example, to distinguish between different {\tt /usr/kvm} volumes.
  406. \Var{karch} defaults to the value of \Var{arch} unless a different
  407. value is set with the ``-k'' command line option.
  408.  
  409. \item[\tt os\hfill]
  410. the operating system.
  411. Like the machine architecture, this is automatically determined at compile time.
  412. The operating system name can be displayed by running the command {\tt amd~-v}.
  413. The currently supported operating systems are listed in table \ref{table:os}.
  414. \begin{table}[htb]
  415. \centering
  416. \begin{tabular}{ll}
  417. Name        & System \\ \hline
  418. \tt acis43    & 4.3 BSD for IBM RT \\
  419. \tt aix3    & AIX 3.1 \\
  420. \tt aux        & System V for Mac-II \\
  421. \tt bsd44    & 4.4 BSD \\
  422. \tt concentrix    & Concentrix 5.0 \\
  423. \tt fpx4    & Celerity FPX 4.1/2 \\
  424. \tt hlh42    & HLH OTS 1.$x$ (4.2 BSD) \\
  425. \tt hpux    & HP-UX 6.$x$ \\
  426. \tt riscix    & Acorn RISC iX \\
  427. \tt sos3    & SunOS 3.4 \& 3.5 \\
  428. \tt sos4    & SunOS 4.$x$ \\
  429. \tt umax43    & Umax 4.3 BSD \\
  430. \tt u2\_2    & Ultrix 2.2 \\
  431. \tt u3\_0    & Ultrix 3.0 \\
  432. \tt utx32    & Gould UTX/32 Rel 2.$x$ \\
  433. \tt xinu43    & mt Xinu MORE/bsd \\
  434. \end{tabular}
  435. \caption{\label{table:os}Operating systems supported by \amd}
  436. \end{table}
  437. \end{list}
  438.  
  439. The following selectors are also provided.  Unlike the other selectors,
  440. they vary for each lookup.
  441. Note that when the name from the kernel is expanded prior to a map
  442. lookup, these selectors are all defined as empty strings.
  443. \begin{list}{}%
  444. {\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
  445. \item[\tt key\hfill]
  446. the name being resolved.
  447. For example, if {\tt /home} is an automount point, then accessing
  448. {\tt /home/foo}\label{foo-path} would set \Var{key} to the string {\tt foo}.
  449. The key is prefixed by the \opt{pref} option set in the parent mount point.
  450. The default prefix is an empty string.  If the prefix was {\tt blah/} then
  451. \Var{key} would be set to {\tt blah/foo}.
  452.  
  453. \item[\tt map\hfill]
  454. the name of the mount map being used.
  455.  
  456. \item[\tt path\hfill]
  457. the full pathname of the name being resolved.  For example {\tt /home/foo}
  458. in the example above.
  459.  
  460. \end{list}
  461.  
  462. Selectors can be negated by using {\tt !=} instead of {\tt ==}.
  463. For example to select a location
  464. on all non-{\sc Vax} machines the selector {\tt arch!=vax} would be used. 
  465.  
  466. \Subsection{Options}\label{options}
  467.  
  468. Options are parsed concurrently with selectors.  The difference is that
  469. when an option is seen the string following the ``{\tt :=}'' is recorded for
  470. later use.  As a minimum the \opt{type} option must be specified.
  471. Each filesystem type has other options which must also be specified.
  472. The filesystem specific options are detailed in \Ref{filesystems}.
  473.  
  474. The following options apply to more than one filesystem type:
  475. \begin{list}{}
  476. {\settowidth{\labelwidth}{{\tt sublink}}\setlength{\leftmargin}{1.2\labelwidth}}
  477. \item[\tt delay\hfill]
  478. the delay, in seconds, before an attempt will be made to mount from the current location.
  479. Auxilliary data, such as network address, file handles and so on are computed
  480. regardless of this value.
  481. A delay can be used to implement the notion of primary and secondary file servers.
  482. The secondary servers would have a delay of a few seconds,
  483. thus giving the primary servers a chance to respond first.
  484.  
  485. \item[\tt fs\hfill]\label{mount location}
  486. the local mount point.
  487. The semantics of this option vary between filesystems.
  488.  
  489. For \NFS\ and \UFS\ filesystems the value of \Var{fs} is used as the local
  490. mount point.  It is important that this string uniquely identifies the
  491. filesystem being mounted.  To satisfy this requirement, it should contain the
  492. name of the host on which the filesystem is resident and the pathname
  493. of the filesystem on the local or remote host.
  494.  
  495. The reason for
  496. requiring the hostname is clear if replicated filesystems are considered.
  497. If a fileserver goes down and a replacement filesystem is mounted then the {\em local}
  498. mount point {\em must} be different from that of the filesystem which
  499. is hung.
  500. Some encoding of the filesystem name is required if more than one filesystem
  501. is to be mounted from any given host.
  502.  
  503. If the hostname is first in the path then all mounts from a particular
  504. host will be gathered below a single directory.  If that server goes
  505. down then the hung mount points are less likely to be accidentally referenced,
  506. for example when {\bf getwd}(3) traverses the namespace to find the pathname
  507. of the current directory.
  508.  
  509. The {\tt fs} defaults to \Var{autodir}/\Var{rhost}\Var{rfs}.
  510. In addition, {\tt rhost} defaults to the local host name (\Var{host}) and
  511. {\tt rfs} defaults to the value of \Var{path}, which
  512. is the full path of the requested file; {\tt /home/foo}
  513. in the example above (\see \Ref{foo-path}).
  514. \Var{autodir} defaults to {\tt /a} but may be changed with the ``-a''
  515. command line option\footnote{Sun's automounter defaults to {\tt /tmp\_mnt}}.
  516. Note that there is no ``{\tt /}'' between the \Var{rhost} and \Var{rfs} since
  517. \Var{rfs} begins with a ``{\tt /}''.
  518.  
  519. \item[\tt opts\hfill]
  520. the options to pass to the mount system call.
  521. A leading ``{\tt -}'' is silently ignored.
  522. The mount options supported generally correspond to
  523. those used by {\bf mount}(8) and are listed in table \ref{table:mount opts}.
  524. Some additional pseudo-options are interpreted by \amd\ and
  525. are listed in table \ref{table:pseudo-mount opts}.
  526. Unless specifically overridden, each of the system default mount
  527. options applies.
  528. Any options not recognised are ignored.
  529. If no options list is supplied the string {\tt rw,defaults} is used
  530. and all the system default mount options apply.
  531. \begin{table}[htb]
  532. \centering
  533. \begin{tabular}{lp{4in}}
  534. Option        & Semantics \\\hline
  535. \tt grpid    & Use BSD directory group-id semantics. \\
  536. \tt intr    & Allow keyboard interrupts on hard mounts. \\
  537. \tt nodevs    & Don't allow local special devices on this filesystem. \\
  538. \tt nosuid    & Don't allow set-uid or set-gid executables on this filesystem. \\
  539. \tt quota    & Enable quota checking on this mount. \\
  540. \tt retrans=$n$    & The number of \NFS\ retransmits made before a user error is generated
  541.           by a {\tt soft} mounted filesystem, and before a
  542.           {\tt hard} mounted filesystem reports {\tt NFS server {\em yoyo}
  543.           not responding still trying}. \\
  544. \tt ro        & Mount this filesystem readonly. \\
  545. \tt soft    & Give up after {\em retrans} retransmissions. \\
  546. \tt tcp        & Use TCP/IP instead of UDP/IP \\
  547. \tt timeo=$n$    & The \NFS\ timeout, in tenth-seconds, before a request is retransmitted. \\
  548. \end{tabular}
  549. \caption{Mount options passed to the mount system call\label{table:mount opts}}
  550. \end{table}
  551.  
  552. \begin{table}[htb]
  553. \centering
  554. \begin{tabular}{lp{4in}}
  555. Option        & Semantics \\\hline
  556. \tt notimeout    & Configures the mount so that its time-to-live will
  557.           never expire.  This is also the default for some
  558.           filesystem types. \\
  559. %
  560. % Implementation broken:
  561. \tt ping=$n$    & The interval, in seconds, between keep-alive pings.  When four
  562.           consecutive pings have failed the mount point is
  563.           marked as hung.  This interval defaults to 30 seconds.
  564.           If the ping interval is negative, no pings are sent and
  565.           the host is assumed to be always up.  Pings are never sent
  566.           for a TCP mount.  \\
  567.  
  568. \tt retry=$n$    & The number of times to retry the mount system call. \\
  569. \tt utimeout=$n$& The interval, in seconds, by which the mount's
  570.           time-to-live\label{opt:utimeout}
  571.           is extended after an unmount attempt has failed.
  572.           In fact the interval is extended before the unmount
  573.           is attempted to avoid thrashing.  The default value
  574.                   is 120 seconds (two minutes) or as set by the ``-w''
  575.                   command line option. \\
  576. \end{tabular}
  577. \caption{Mount options interpreted by \amd\label{table:pseudo-mount opts}}
  578. \end{table}
  579.  
  580. \item[\tt sublink\hfill]
  581. the subdirectory within the mounted filesystem to which the reference
  582. should point.
  583. This can be used to prevent duplicate mounts in cases where multiple
  584. directories in the same mounted filesystem are used.
  585.  
  586. \item[\tt type\hfill]
  587. the filesystem type to be used.  A full description of each
  588. type is given in \Ref{filesystems}.
  589.  
  590. \end{list}
  591.  
  592. Superfluous option specifications are ignored and are not reported
  593. as errors.
  594.